One of the most powerful tools you can utilize to improve your Solaris 2.x system's administrative organization is the NIS+ naming service. NIS+ is a component of ONC (Open Network Computing), a family of networking products designed for implementing distributed computing in a multivendor environment. Its main function is to simplify system and network administration. But if it simplifies administration, you might think that NIS+ represents a possible security problem.
As a Solaris 2.x system administrator, one of your primary concerns
is security. The advantage of using NIS+ is that it makes your
job easier while providing you with the tools and procedures for
keeping your network secure. In this article, we'll take a look
at the NIS+ naming service security and show you how to keep your
security risks at a minimum when using NIS+.
When looking for a potential security problem, you can break down the risks into two basic groups. First, you should consider user access. If you have a large distributed network with several NIS+ namespace servers, you should create user accounts for these systems based on administrative needs. In addition, you should configure the appropriate user credentials for anyone accessing the NIS+ service.
The second group of security concerns is what we'll call signal
security. Whether your NIS+ distributed network operates internally
or across the Internet, you need to ensure that outsiders can't
compromise the integrity of your network and the packets contained
within your network signal. To begin our discussion of NIS+ security
for Solaris 2.x systems, let's take a look at some of the security
features within the naming service.
To understand NIS+ security, you should realize that in its most basic form, NIS+ manages database files called tables, which contain information on your network systems and users. How NIS+ organizes these database files and how it can distribute them across various systems on your network represents the core of the NIS+ naming service.
The security features of NIS+ protect information in the namespace,
as well as the structure of the namespace itself, from unauthorized
access. Without these security features, any NIS+ client could
obtain and change information stored in the namespace. NIS+ provides
security by two means: authentication and authorization.
Let's take a look at these two functions.
When an NIS+ client makes a request, NIS+ identifies the client as the NIS+ principal. When a principal makes a request, NIS+ uses authentication as a mechanism to verify the principal's credentials. NIS+ principals have two types of credentials: LOCAL and DES. A client user can have both types of credentials, but a client workstation can have only a DES credential.
A LOCAL credential is simply the UID of an NIS+ principal. Since the UID of every workstation is zero, a client user can't use a LOCAL credential.
A DES credential is more complex than a LOCAL credential. Both workstations and users can be principals with the DES credential. The DES credential contains the principal's secure remote procedure call (RPC) netname and a verification field. The secure RPC netname of the credential is the part used to actually identify the NIS+ principal.
Every secure RPC netname begins with the prefix unix. If the principal is the client user, the second field in the netname is the user's UID. If the principal is a client workstation, the second field in the netname is the workstation's hostname. The last field in the principal's netname is its home domain.
The verification field information contained in a DES credential makes sure that a credential isn't forged. The information in this field contains credential information stored in the Credential table of the NIS+ host domain.
After NIS+ authenticates a principal, it determines the access
rights of the client user or client workstation. The authorization
portion of NIS+ verification determines the access rights.
If NIS+ authenticates your request, you'll then be classified
as a principal in one of four authorization categories. These
four categories are
Once a principal is assigned an authorization category, the requested
object's access rights must be appropriated for various access
levels. Similar in form to the familiar UNIX read/write file permissions,
the access rights for NIS+ objects are set with read, modify,
create, and destroy privileges. As an example of these access
rights, let's look at the access privileges of a sample NIS+ object:
r---rmcdrmcdr---
From these rights, we can see that Nobody, represented by the
first four fields in the access rights, has read permissions only.
The next four fields represent the Owner principal's rights, which
include all available access levels. The next four fields represent
the Group principal's access rights, and the final four represent
the rights of the World principal.
In this article, we've given a broad overview of security within the NIS+ naming service for Solaris 2.x systems.
[Return to Index for Inside Solaris - January Issue]
Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis
Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of
Ziff-Davis Publishing Company.